home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Peanuts 2
/
Peanuts - Issue 2 (Alcatraz).adf
/
GIFconvert.DOC
< prev
next >
Wrap
Text File
|
1992-05-31
|
12KB
|
289 lines
------------------------------------------------------------------------
GIFconvert v2.12
Written by Geert Coelmont
------------------------------------------------------------------------
Quick Documentation
------------------------------------------------------------------------
0. History
----------
Often, Amiga-freaks and PC-freaks don't like eachother, and it's all
about whose computer is the best. Well, there really is no doubt about
the answer, but the problem is to make it clear to those DUMBOS.
War was raging high in our school. That's when the SVGA-craze started.
Suddenly every PC-freak turned into a Video-Profi and compared to the
Amiga, his SVGA card could display MANY MANY MANY more colors, (all
very similar, but still....) and he showed me some cool pictures he
got when he bought his SVGA+MultiSync. Not that many other software
supported his Very-Very-High-Resolution Graphics, but this single
slideshow did, and he had about 10 disks stuffed with it !
No problem MAN ! Amiga can do it too !!!! Without mega-expensive
monitors and expansioncards. And I started coding...
After some weeks of research and hard work, the result is there, and
it is called >> G I F c o n v e r t <<
1. What is GIFconvert ?
-----------------------
GIFconvert is a small utility that will display 'GIF' pictures on
any Amiga, and optionally save them in IFF, so you can use it
together with most other Amiga software.
2. What is GIF ?
----------------
'GIF' is a kind of graphics storage format, similar to IFF, but
typically created for IBM-PC's with their silly VGA/EGA cards.
They support a palette of 256 colors out of 16777216 (256*256*256).
3. Why GIFconvert ?
-------------------
Converting EGA/VGA to HAM will in most cases cause some loss of
quality, but GIFconvert uses some cool routines that reduce this loss
as much as possible. GIFconvert will automatically switch to the most
appropriate resolution and display mode to get the most out of your
Amiga. The HAM-routine is really smart and will get rid of those ugly
colortransitions that are typical for HAM. (see chapter 4)
By the way: New resolutions like Productivity and what's-its-name are
not supported (yet?) because I don't have any documentation about the
registers, and I can't test them anyway.
4. The difference between EGA/VGA and HAM
-----------------------------------------
EGA and VGA are 'standards' in the PC scene. 'Standards', but there
exist hundreds of different types, dozens of which are incompatible
to eachother. (that is only to demonstrate (again) the hopelessness
of the PC-environment)
Anyway, in VGA, colors use 24 bits of data. (256 steps in Red, 256
in Green and 256 in Blue). So alltogether there are 256^3=16 million
different colors to be chosen from, but each picture can use only
256 of them at a time, they can be freely chosen and are stored
together with the image. Each pixel in the image refers to one color
in this palette of 256 colors, and obviously, 8 bits are needed for
that.
On the Amiga, colors use only 12 bits of data: 4096 colors. In normal
display modes, the same technique as in VGA is used: a palette is
defined and the image refers to the colors in the palette. For
32-colored pictures, 5 bits per pixel are required.
The HAM-technique takes it a different way. A palette can be defined
as described before, but a pixel does not necessarily have to refer
to one of these palette-colors. A pixel can in fact be two things:
- An absolute color, one of the 16 defined in the palette,
- A RELATIVE color, derived from the pixel to the left.
A relative pixel simply takes the RGB-value of the previous pixel
(the one to the left) and changes ONE of its components: Red, Green
or Blue. That's where the name 'Hold-and-Modify' comes from. Two
components are HELD, one is MODIFIED.
This method implies that sudden colorchanges are not possible;
changing from one color to a different one, will be done in maximum
3 steps: one step for each component. As a result, you might find
some pixels in wrong color between two different colored surfaces.
A solution for this colortransition is ofcourse the palette. If a
color was defined in the palette, it can be adressed immediately,
without the 3 steps. Only problem is that there are only 16 colors
to be defined in the palette, so it's up to the software to do the
best possible selection.
Now what is the benefit of this complex method of adressing a pixel's
color ? Well first of all, it was designed for use with digitized
images, because they mainly consist of smooth colorchanges. I've
heard the technique is used too in the TV-scene somewhere, but I'm
not sure about that.
Anyway, the main advantage is that you can address 4096 colors with
only 6 bits of data for each pixel (check it out):
bit 0,1,2 and 3 are the main bits, they form a number between 0 and
15. Bit 4 and 5 are the control bits, they decide what bits 0-3
stand for:
4 | 5
--+--
0 | 0 Bit 0-3 are used as absolute reference to one of the 16
| colors in the palette: i.e. 12 refers to color12
0 | 1 Bit 0-3 are used as NEW value for the RED component, the
| Blue and Green components don't change.
1 | 1 Bit 0-3 are used as NEW value for the GREEN component,
| the Blue and Red components don't change.
1 | 0 Bit 0-3 are used as NEW value for the BLUE component,
| the Red and Green components don't change.
As you now can see, in maximum 3 steps, HAM can address any of the
4096 colors with only 6 bits of data, where the VGA technique
already uses 8 bits of data to address only 256 colors !
5. Usage
--------
GIFconvert is only used from CLI. The syntax is fairly simple:
1) GIFconvert ?
Will display a short message and my address (in case you still
don't know it!)
2) GIFconvert [options] <GIF-filename> [<IFF-filename>]
<GIF-filename> Obviously is the name of the picture to be
converted. If this file is not found in the
specified path, the extension '.gif' will be
added, and another attempt to find the file
is made.
<IFF-filename> If this parameter is specified, the converted
picture will be saved in IFF under this name.
If no iff-filename was given, the picture will
only be shown. Please note that GIFconvert was
not intended to be a picture-viewer (it is too
slow for that @#$%! see chapter 6)
[Options] can be one or more of the following:
-t<path> : GIFconvert uses 2 temporary files (due to the
decrunch-routine, which in fact is an object-
file, launched from within GIFconvert)
By default, GIFconvert uses RAM: to store these
files in. With the '-t' option you can force
them to another path, for example if you are
low on ram, you could specify: -tDF0: which
would save the temporary files on DF0:
A slash (/) is added to the path if necessary.
-d : By default, the partially converted picture is
being displayed during Pass3. The '-d' option
will hide the picture, so you can run GIFconvert
in the background, without being interrupted.
Please note that this option only makes sense
when you want to save the converted picture,
specifying an <IFF-filename>.
-s : GIFconvert will normally try to fit the GIF-
picture on the screen, by turning on interlace
or hires, or even by skipping pixels in the
display. This option will force GIFconvert to
keep the original size of the GIFpicture. No
transformation is done.
Examples: 1> GIFconvert testpic
Will display the picture called TESTPIC (or TESTPIC.GIF)
Once the picture is fully converted, click mouse to exit.
1> GIFconvert -d -tdf0:t pc0:testgif dh0:pics/testiff
Will convert the picture in PC0: called TESTGIF (or
TESTGIF.GIF), without displaying it, and using DF0:T as
the Temporary Files-directory. The converted picture
is saved as 'DH0:pics/testiff'
6. Help wanted !
----------------
GIFconvert upto version 2.1 uses a C-object file to decrunch the
pictures, which is V.E.R.Y. slow, but I don't have the sourcecode,
and it is CRAZY to attempt resourcing it, I've tried !
I've done some efforts in patching parts of the code with own-written
stuff, but the results are poor. S O P L E A S E:
Does ANYbody have a GIF-decrunchalgorithm in ANY language ? If you
do, please send it and I will throw out the old routie and rewrite
it in megafast Assembler.
7. Credits and Info
-------------------
The decrunch-routine is called GIFtoTMP, and was written by Marc
Podlipec in 1989. I don't know the author personally, and I don't
have his address. I just found this tool on a disk long ago. I hope
he doesn't mind me using it. No copyright notices were found so I
guess it was OK.
All other routines were written in assembler by myself, and they
should be system-friendly (except the picture-display, which kills
systemroutines for a while. Use the '-d' option!)
GIFconvert was succesfully tested under kick1.2, kick1.3 and
kick2.0 (Zkicked).
GIF-images using 16 and 256 colors were tested, resolutions from
1024 horizontally and 780 vertically. I've read about multiple
images in ONE gif-file, but I haven't encountered them so far.
If you have a GIF-picture that causes problems, please send it to
me ASAP. You will be rewarded with credits and ofcourse the new
version as soon as it is available.
Here's the address:
Geert Coelmont
Eikenlaan 21
3740 Bilzen
BELGIUM
Please note that GIFconvert is SceneWare, which means you must
spread it if you like it, but COMMERCIAL use (outside the scene)
is NOT allowed without my written permission. Ofcourse PUBLIC DOMAIN
is just as commercial as any SoftwareHouse, so the restriction
applies to them as well.
Finally, credits must go to:
- Marc Podlipec for the decrunch-program
- Koen Peetermans, Mike Erasmus and Jan Steegmans for the support
and the test-pictures
- Romain V. and Ronny W. for the uploading
- You for using and spreading this tool !
- Commodore for supplying us with the best computer ever !
8. Quick Development Overview
-----------------------------
v0.0 Was jealous about SVGA. Found a tool called 'GIFtoTMP'.
Did some research on this 'TMP'-structure. Messed around
with HAM.
v0.9 'very-pre' release. I had only 1 picture to test with.
v1.0 Removed some Mega-bugs. First official release. No save
option was built-in. (it was still called 'ShowGIF')
v1.1 Some more small bugs cut out. Never released.
v1.2 Many special-format pictures tested, wider-than-screen-
images will now display correctly.
v2.0 Highly improved version, supports Hi-res and Interlace.
IFF-save enabled. HAM-pallette now used for (much) better
results. Typed some worthless DOCS. Released at TRSI-
party in Leuven. Now called 'GIFconvert'.
v2.1 Runtime options -d, -t and -s added. Better argument
parser. You now can break the decruncher with 'CTRL-C'.
Small bug in IFF-save removed. '.GIF' is added to the
input-filename automagically, because I was too lazy to
type it myself. DOCS updated (lame job!)
v2.12 Runtime options cleaned-up: '-d' screw up the saved IFF
picture.